Seems #![feature(step_trait)] is not acceptable.

Without this trait, the performance reduces by 16%.

sort-limit 2^14 f32     time:   [53.572 us 53.758 us 53.967 us]                                
                        change: [+15.351% +16.099% +16.909%] (p = 0.00 < 0.05)
                        Performance has regressed.

The only way currently I can find to reduce hot path from_usize().unwrap() is to add a method buffer_from_range in trait Index.

Codecov Report

Merging #246 (22d58cf) into main (eea4d33) will decrease coverage by 0.12%.
The diff coverage is 52.32%.

@@            Coverage Diff             @@
##             main     #246      +/-   ##
==========================================
- Coverage   76.81%   76.68%   -0.13%     
==========================================
  Files         229      229              
  Lines       19617    19675      +58     
==========================================
+ Hits        15068    15087      +19     
- Misses       4549     4588      +39     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update eea4d33...22d58cf. Read the comment docs.

I can see that there is some limitations with stable Rust wrt to the ranges and indices. I will take a stab at addressing this here, to see if we can get the remaining performance out of this without the from_usize around.

I think that #247 addresses the limitations; could you take a look and see what do you think?

I have also created https://users.rust-lang.org/t/idiomatic-way-to-populate-vector-from-branched-loop/63152 to see if we get good ideas.

Update:

Add shrink_to_fit() to fix #249

I think that #247 addresses the limitations; could you take a look and see what do you think?

Ok, I'll take look at that.

I will go ahead and merge this, and clear up the API in a follow-up PR. Thanks a lot, @sundy-li !